A mobile radio communication system includes a mobile radio communication network communicating with mobile terminals or UEs (User Equipments) and with external networks. Traditionally, communications are facilitated using one or more radio base stations that provide radio coverage for one or more cell areas and control traffic to and from a cell in the system. Base stations and the mobile terminals are able to send and receive data blocks, which may comprise sequence numbers, to and from each other.
Within the framework of GSM EDGE Radio Access Network (GERAN) in 3GPP, an event-based protocol uses ACK/NACK messages that are “piggy-backed” on data packets being sent in the opposite link direction. An event is an error in the transmission detected by the receiver. According to 3GPP/GERAN 44.060, ver. 8.3.0, a Piggy-Backed ACK/NACK (PAN) report can be sent from the mobile station (MS) and/or from the base station system (BSS). The PAN report is included in the feature Fast Ack/Nack Reporting (FANR) which is part of EDGE Evolution in Release-7 of 3GPP/GERAN.
These piggy-backed ACK/NACK reports (PANs) can include a combination of Block Sequence Numbers (BSN) that identify outstanding radio data blocks and bitmaps giving ACK/NACK information of radio blocks after a specified BSN. A PAN report can include a Beginning-Of-transmission Window bit (BOW), a Starting transmitted data block Sequence Number (SSN), and an ACK/NACK bitmap (reported bitmap RB). FIG. 1 shows the different fields in a PAN report as specified in 3GPP/GERAN. The BOW field indicates whether the beginning of the window (i.e., the blocks before the SSN) is covered by the PAN report or not. The Short SSN field is the data block number of where the PAN report starts. The ACK/NACK bitmap field (reported bitmap RB) includes the actual ACK/NACK bits where each bit indicates an ACK or NACK of a certain data block specified by the Short SSN plus the position of the bit in the ACK/NACK bitmap RB. A transmit format indicator (TFI) may also be included.
The transmission of data and the PAN report from the sender to the receiver takes a certain amount of time referred to as a PAN round trip time (RTT) which includes the time associated with the sender sending a data block, the receiver receiving the data block, the data block being processed to determine if it is correctly received, generating an ACK/NACK message for that data block, transmitting the ACK/NACK message, and receiving the ACK/NACK message back at the sender. Data and PAN reports can be sent in the uplink (UL) and/or downlink (DL) direction simultaneously, which means they can be in transmission at the same time. Therefore, the sender may have just sent some data while the intended receiver of that data may have sent a PAN report back to the sender. A problem with this situation is that the sender can not know whether the data it sent arrived at the receiver before or after the PAN report was sent by the receiver.
One approach to solving this problem in 3GPP/GERAN is for the base station to inform the mobile station what round trip time (RTT), as defined above, is for that particular mobile station. The mobile station may then use that RTT when calculating whether a specific bit in the ACK/NACK bitmap (reported bitmap RB) indicating an ACK for a block or a NACK for a block is valid or not. In the current implementation for the GERAN standard, this estimated RTT is broadcasted in a semi-static fashion by the base station to all mobiles stations in a given cell with the name “BS_CV_MAX.” But a serious drawback with this approach is that the actual RTT can vary substantially both between (different types of) cells and within a given cell over time, for example, due to transport load (e.g., high load during the day, low load during night, etc.) or transport type (e.g., optical cable, microwave, satellite, etc.).
This variance in actual current RTT from the broadcast RTT produces two problems. One is that a broadcast RTT longer than the actual RTT causes NACKs to be improperly ignored. The other is that a broadcast RTT shorter than the actual RTT causes unnecessary retransmissions of data blocks. These RTT variances are particularly problematic, although not limited to, situations where data is sent uplink from the mobile station to the base station, and PANs are sent downlink from the base station to the mobile station.
FIG. 2 helps illustrate the first problem in a GERAN context. In the first scenario (solid lines), the mobile station (MS) sends a data block X that the base station system (BSS) should have received at time 2), unless it was lost or corrupted in transmission. The BSS sends a PAN that the MS receives at time 4). Since the PAN is received after the BS_CV_MAX (the broadcast RTT) expires, a NACK is registered for the data block X not properly received in time by the MS. The MS then responds to the NACK by retransmitting data block X.
In the second scenario (dotted lines) shown in FIG. 2, the MS sends a data block Y that the BSS should have received at time 1), unless it was lost or corrupted in transmission. The BSS sends a PAN that the MS receives at time 3). Since the PAN is received before the BS_CV_MAX (the broadcast RTT) expires, the MS ignores a NACK for the data block Y and does not retransmit block Y. This action by the MS is based on the assumption that BS_CV_MAX (the broadcast RTT) matches the broadcast RTT (an estimate) with the actual RTT and that in this case the BSS could not have received the data block Y before sending the PAN to the MS. This second scenario of a BS_CV_MAX (the broadcast RTT) being longer than the actual RTT is common in real life EDGE and EDGE Evolution deployments.
FIG. 3 shows a scenario where MS sends a data block Z and the BSS sends two different PANs and where the BSS broadcasted RTT (BS_CV_MAX) defines a certain timer value for the MS. When the MS receives a PAN at time 3) sent at time 1), as shown with dotted lines, the MS validates the ACK/NACK information in the PAN with respect to the BS_CV_MAX (the broadcast RTT) and concludes that the data block Z should have been received. But because the actual RTT is longer than BS_CV_MAX (the broadcast RTT), the BSS does not explicitly NACK data block Z. However, the BSS nevertheless sets the NACK bit for data block Z in the PAN bit map RBB to “not received,” even though the actual RTT has not yet expired and it is not yet possible for the MS to determine whether data block Z was properly received. The MS wrongly concludes that the BSS should have received data block Z (RTT check) and that data block Z has been lost. As a result, the MS re-transmits data block Z unnecessarily. This scenario is an example of a BS_CV_MAX (broadcast RTT) being shorter than the actual RTT.
In addition, the MS will be confused when the PAN is received at later time 4) corresponding to the actual RTT indicating that data block Z is ACKed. This may cause the complete PAN report to be discarded since this is the specified action to be taken in case a NACK from one PAN report is changed to ACK in consecutive PAN reports.
These examples demonstrate that some data blocks successfully received by the BSS are unnecessarily re-transmitted. This results in wasted bandwidth, decreased spectrum efficiency, increased delays, negative end-user performance, and unnecessary use of processing and transceiving resources. One example also shows that some data blocks not successfully received by the BSS are never re-transmitted. This results in very large delays and negative end-user performance.